Real-time communications events including audio and/or video conferencing are known on communications networks such as packet-based networks, including internet protocol (“IP”) networks. Often, these may be implemented across large networks to allow tens, hundreds, or even more individual connections to communicate with one another. Generally, a communications event application runs somewhere on the network. This application may connect users to the event, manage data flow between the users, provide some security, and perform other event management functions.
Often a client-server architecture is used, which is well known in the art. In this architecture, the server runs applications for the benefit of the client. Within a communications event, participants are clients and the event application software that manages the event resides on a server computer. Often these communications events may include use of many applications, including video, audio, security, playback, data sharing, and the like. Each of these applications may require one or more software utilities running on and managed by the server.
Unresolved needs and problems are associated with this known configuration and architecture. For example, the communications event heavily depends on the event server. Any problems with the server may cause difficulties with the event, or may even cause the event to fail. Depending on the number of participants, data streams, applications, and other like factors, the demands on an event server can be high. For very large conferences with tens or even hundreds of participants, even very powerful servers are under a heavy burden. Accordingly, it is not unusual that server problems, and in turn problems with communications events such as a videoconferences hosted on these servers, are encountered. Failure of the server may cause the event to fail.
In some applications multiple event servers may be running to interface very large numbers of participants with one another. When this occurs, the servers may need to communicate and coordinate with one another. Failure of one of many servers can cause the entire event to fail. Although if a first server fails a second server can conceivably be put into service, an interruption of service typically results while a user determines the location of the new server and connects to it. Accordingly, unresolved needs exist relating to the stability and redundancy of communications event platforms.
Also, when adding new applications or clients to an existing communications event architecture, each instance of the event server must be modified to configure that application. This can be particularly difficult for large installations where multiple event servers are present. Also, from the perspective of a communications software vendor/installer/administrator perspective, the burden associated with introducing new software applications and versions is high since every existing event server needs to be modified. Accordingly, unresolved needs exist relating to the implementation and maintenance of communications event platforms.
Many known client/server communications event architectures also do not scale well. That is, expansion in number of clients, applications, capabilities, modifications, or the like can be burdensome. Simply adding additional users to an existing server taxes that server's ability to perform. Stability issues may arise. Adding new servers is burdensome. Accordingly, unresolved needs exist relating to the scalability of communications event platforms.
Other existing problems of the prior art include configurations wherein a single software processes running on one computer provides multiple different functional services. For example, a single software instance running on one computer may provide conference bridge connection services, recorder services, attendee authentication services, and the like. If a problem is encountered with any one of these services, the entire software instance may fail thereby causing loss or interruption of the conference.
Still another problem in the art relates to allocation of resources for a video conference or other data sharing event. Such events typically require a software component that may be referred to as a conference bridge to be running to link the users to one another. The conference bridge may, for example designate ports for communications to be routed over and otherwise control communications traffic between users. Conference bridges can be burdensome on a network, however, and can consume considerable resources. Also, conference bridges can be subject to errors or bugs. Many known conference bridges are deployed on a network to support the predicted peak conferencing load on that network. When the load is less than that predicted peak, unnecessary resources are consumed by the un-needed bridges. Also, because the bridges are constantly running, they risk encountering an error that may disrupt their operation. While these errors can often be resolved by resetting the bridge, such resetting requires close monitoring of the bridge and disruption in service as the bridge is shut down and reset.
These and other problems remain unresolved.